Method and system for sender-controlled messaging and content sharing

ABSTRACT

An access-control device that controls access to encrypted messages. During operation, the access-control device can receive an access key for a corrupted message, and can receive a cover message digest associated with the corrupted message. The access-control device stores the access key in association with the cover message digest, and stores the cover message digest in a block chain. A respective block of the block chain includes at least one cover message digest, and a hash value of a previous block of the block chain.

RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 15/696,856, Attorney Docket Number PRIV15-1001DIV, entitled “METHODAND SYSTEM FOR SENDER-CONTROLLED MESSAGING AND CONTENT SHARING,” byinventors Shaun Murphy, Charles Murphy, and Richard Johnson, filed 6Sep. 2017, which is a divisional application of U.S. application Ser.No. 14/874,346, Attorney Docket Number PRIV15-1001US, entitled “METHODAND SYSTEM FOR SENDER-CONTROLLED MESSAGING AND CONTENT SHARING,” byinventors Shaun Murphy, Charles Murphy, and Richard Johnson, filed 2Oct. 2015, which claims the benefit of U.S. Provisional Application No.62/183,855 Attorney Docket No. PRIV15-1001PSP, entitled “METHOD ANDSYSTEM FOR CONTROLLING ACCESS TO ENCRYPTED DATA,” by inventors ShaunMurphy, Charles Murphy, and Richard Johnson, filed 24 Jun. 2015, thedisclosures of which are incorporated herein in their entirety.

The subject matter of this application is related to the subject matterin a non-provisional application by the same inventors as the instantapplication and filed on 4 Jun. 2012 entitled “CONFIDENTIAL MESSAGEEXCHANGE USING BENIGN, CONTEXT-AWARE COVER MESSAGE GENERATION,” havingapplication Ser. No. 13/488,391, Attorney Docket No. PRIV13-1000US, andissued on 15 Jul. 2014 as U.S. Pat. No. 8,782,409, the disclosure ofwhich is incorporated by reference herein.

The subject matter of this application is related to the subject matterin a non-provisional application by the same inventors as the instantapplication and filed on 30 May 2013 entitled “METHOD AND SYSTEM FORAUTOMATIC GENERATION OF CONTEXT-AWARE COVER MESSAGE,” having applicationSer. No. 13/906,039, Attorney Docket No. PRIV13-1001US, and issued on 23Dec. 2014 as U.S. Pat. No. 8,918,896, the disclosure of which isincorporated by reference herein.

BACKGROUND Field

This disclosure is generally related to messaging and content sharing,and facilitating secure communication between two devices. Morespecifically, this disclosure is related to a messaging and contentsharing platform with sender-controlled security and other features.This disclosure is also related to an access-control device thatcontrols access to encrypted data.

Related Art

As an increasing number of users come online, they discover the joys andpitfalls of communicating over the Internet. Users find that they liketo share content and communicate with each other over Internet. However,as many users have realized too late, once their e-mail has been sentout they no longer have control how their e-mail is being used. Theire-mails and other communications can be forwarded to others and quicklyspread beyond their intended audience. This can have a detrimental oreven devastating effect on the original sender, who did not intend thereading audience to expand beyond the original recipient. Therefore, abetter way for users to control their communications is needed.

SUMMARY

One embodiment provides a personal computing device that can push dataobjects to one or more intended recipients. During operation, thecomputing device can obtain a data object being published by a user. Thecomputing device can generate a partial message that includes a subsetof the data object, and can send the partial message to an intendedrecipient of the data object, without first receiving a request for thedata object from the intended recipient.

In some embodiments, the intended recipient can include a remotepersonal computing device, a remote personal storage device, and/or astorage server.

In some embodiments, the computing device can generate an access keythat includes at least one section of the data object that are not inthe partial message, and may send the access key to an access-controldevice that controls access to the data object, or to a storage server.

In some embodiments, while generating the partial message, the computingdevice can identify, from the data object, one or more data blocks thatare to be made corrupt. The computing device may then extract segment ofa respective data block to make the respective data block corrupt, andmay combine the corrupt data blocks to form the partial message.

In some embodiments, the computing device can generate a cover messagefor the data object, and can send the cover message to the intendedrecipient to facilitate the intended recipient to obtain the data objectbased on the cover message.

In some variations on these embodiments, the computing device cangenerate a digest from the cover message, and can send the digest to anaccess-control device that controls access to the data object.

In some embodiments, the cover message can include an email message, ashort message service (SMS) message, an instant messaging (IM) message,a message posted on a social media service, and/or an audio recording.

In some embodiments, the computing device can encrypt the data objectusing a predetermined encryption key to produce an encrypted message.Moreover, while generating the partial message, the computing device canobtain the at least one sections from the encrypted message, and cangenerate the partial message to include the at least one sections of theencrypted message.

One embodiment provides an access-control device that can control accessto encrypted messages. During operation, the access-control device canreceive an access key for a data object being shared with at least oneintended recipient, and a digest associated with the data object, andmay store the access key and the digest in a look-up repository. Whenthe device receives a request for the data object from a remote device,the device may obtain a second digest from the request. Moreover, thedevice may analyze the second digest to determine whether the seconddigest is valid. If the second digest is valid, the device may returnthe access key to the remote device.

In some embodiments, while storing the digest, the device may store thedigest in a block chain. A respective block of the block chain caninclude at least one digest, and/or a hash value of a previous block ofthe block chain.

In some embodiments, the access-control device may be a member of adistributed hash table. When the device stores the digest in the blockchain, the device may proceed to synchronize the block chain with atleast one other member device of the distributed hash table.

In some embodiments, while returning the access key to the remotedevice, the device can perform a lookup operation, using the digest asinput, to obtain an access key that includes the remainder of the dataobject. The access-control device can return the access key to theremote device.

In some embodiments, while validating the second digest, the device mayperform a lookup operation in the block chain to determine whether thesecond digest exists in the block chain.

In some embodiments, the device can return a negative-acknowledgement(NACK) message if the second digest does not exist in the block chain.

In some embodiments, the device can return an acknowledgement (ACK)message if the second digest exists in the block chain.

In some embodiments, if the second digest exists in a block of the blockchain, the device may validate the block. If the block is valid, thedevice may return an acknowledgement (ACK) message.

In some embodiments, if the block is not valid, the device may return anegative-acknowledgement (NACK) message.

In some embodiments, while validating the block, the device candetermine whether a neighboring block in the block chain includes a hashvalue that matches the block's hash value, and/or can determine whetherthe block and a corresponding block of a remote access-control devicehave matching hash values.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an exemplary network environment that facilitates amessaging and content sharing platform with sender-controlled securityin accordance with an embodiment.

FIG. 2 presents a flowchart illustrating a method for sending a messageand/or content to a recipient in accordance with an embodiment.

FIG. 3 presents a flowchart illustrating a method for receiving amessage and/or content in accordance with an embodiment.

FIG. 4 presents a flowchart illustrating a method for anonymouslyaccessing an external service in accordance with an embodiment.

FIG. 5 presents an illustration of a screen that allows a user to setrules for a new message in accordance with an embodiment.

FIG. 6 presents an illustration of a screen that allows a user to changepermissions on all recipients of a new message in accordance with anembodiment.

FIG. 7 presents an illustration of a screen that shows an exemplaryhierarchical display of group messages in accordance with an embodiment.

FIG. 8 illustrates an exemplary computer system that facilitates amessaging and content sharing platform with sender-controlled securityin accordance with an embodiment. In the figures, like referencenumerals refer to the same figure elements.

FIG. 9 illustrates an exemplary network environment that facilitatesprotecting a user's communications over a computer network in accordancewith an embodiment.

FIG. 10 presents a time-space diagram illustrating an exemplary processfor automatically generating context-aware cover messages in accordancewith an embodiment.

FIG. 11 presents a flowchart illustrating a method for automaticallygenerating a context-aware cover message in accordance with anembodiment.

FIG. 12 presents a flowchart illustrating a method for uploading, to atopic server, a list of topics relevant to local context in accordancewith an embodiment.

FIG. 13 presents a flowchart illustrating a method for creating a blockchain entry for a secure message in accordance with an embodiment.

FIG. 14 presents a flowchart illustrating a method for receiving a covermessage and obtaining a corresponding secure message in accordance withan embodiment.

FIG. 15 illustrates an exemplary computer system that facilitatesautomatic generation of context-aware cover messages for securecommunication in accordance with an embodiment.

In the figures, like reference numerals refer to the same figureelements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the embodiments, and is provided in the contextof a particular application and its requirements. Various modificationsto the disclosed embodiments will be readily apparent to those skilledin the art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present disclosure. Thus, the present invention is notlimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features disclosed herein.

Overview

Embodiments of the present invention solve the problem of providingsender-controlled messaging and content sharing security by allowing auser to set rules and permissions to control the use and lifecycle ofmessages and/or other content. A messaging and content sharing platformand system includes a client installed on each mobile device that allowsa sender to set permissions and rules for a message or content. Thesepermissions and rules give the sender complete control over how areceiving party may use the message and/or content. For example, asender may disallow the receiving party from forwarding, taking ascreenshot, printing, or downloading the message. The sender may alsorequire that the receiving device delete the message after taking ascreenshot or after the user views the message. Note that embodiments ofthe present invention are not limited to the disclosed examples.

The messaging and content sharing platform may also feature ahierarchical display for group messaging that utilizes a tree structureto illustrate the threads of a conversation when multiple users arecommunicating with each other. This allows the user to easily follow thegroup conversation and see who is messaging whom in the conversation.

The messaging and content sharing platform may also include anattachment-only view so that a user can scroll through the list of fileattachments and filter attachments to find what they need. Theattachment-only view may apply system-wide (e.g., in the inbox, contactview, and message view). The attachment-only view may be availableanywhere a file may be associated with a system object or action. Thesystem may allow for large file attachments (e.g., one terabyte orgreater). Management of large file attachments is transparent to theuser and users do not need to separately upload large files to anotherserver themselves.

Some embodiments may also include a zero-login feature that allows auser to use an external service, such as a social networking service,without logging in. The user can use the social networking serviceanonymously to contact others until the user wants to authenticate hisidentity with the external service.

Exemplary Network Environment

FIG. 1 illustrates an exemplary network environment 100 that facilitatesa messaging and content sharing platform with sender-controlled securityin accordance with an embodiment. Network environment 100 can include acomputer network 102, which can include any wired or wireless networkthat interfaces various computing devices to each other, such as acomputer network implemented via one or more technologies (e.g.,Bluetooth, Wi-Fi, cellular, Ethernet, fiber-optic, etc.). In someembodiments, network 102 includes the Internet.

Network environment 100 can also include a computing device 104, which auser 106 uses to communicate a message or content to another computingdevice, such as computing device 110 or computing device 112. User 114operates computing device 110 and user 116 operates computing device112. User 106 may use a messaging and content sharing client 118installed on computing device 104 to send messages or other content tothe other users. The message or content can be text, voice, and/orvideo. Client software 118 allows a user to send messages, messageattachments, files, and other content. Computing device 110 andcomputing device 112 also have installed messaging and content sharingclients 120, 122 respectively. User 106 may also anonymously accessexternal services, such as social networking service 123. Although FIG.1 depicts computing device 104 as a smartphone, computing device 104 canbe also be a personal computer or any device that user 106 can use tosend messages or share file/content with user 112.

A messaging and content sharing server 124 can store and execute serversoftware, and may store content such as files or attachments frommessages that a user shares with others. The system may split up a fileso that malicious attackers have greater difficulty finding andreassembling the separate parts of the encrypted file. Server 124 canstore small portions of encrypted files and/or large portions of theencrypted files. The system may also send a large portion of anencrypted file to an enterprise hardware device, such as an enterpriseserver 126, for storage. Further, the system may store a large portionof the encrypted file using cloud storage services, such as cloudstorage server 128. Note that generally the system can split apartobjects (encrypted or not), and store a portion of the object in onelocation and the remainder of the object in any number of otherlocations, the details of which are further disclosed in U.S.Provisional Application No. 62/183,855. Objects may include, but are notlimited to, pictures, videos, documents, text messages, emails, andother digital items.

Permissions and Rules

A user may control the use of messages or other content usingpermissions and rules. A permission associated with an object, such as amessage and/or content, indicates an operation that a receiving devicemay perform on the object. The user may set one or more permissions tocontrol the operations that the recipients can perform with themessages/content. For example, the user may set permissions to allow orprevent forwarding a message, locally download an attachment, andadd/remove a participant in a group message. The user may also setpermissions to allow or prevent taking a screenshot, printing, and/orarchiving a message or content. The user can set default permissionsthat apply globally or per contact. The user can also set fine-grainedpermissions, such as permissions that apply per user and/or perattachment. Furthermore, the user may change the permissions at anytime.

A rule associated with an object, such as a message and/or content,indicates an operation that the receiving device performs when aspecified condition or event occurs. For example, a rule may specifythat a receiving device delete a message and/or content after it hasbeen read. Another rule may specify that a receiving device delete amessage and/or content after a certain time period. Another example of arule is that a receiving device is required to delete all messagesand/or content sent to a user if the user tries to take a screenshot ofthe message and/or content. As another example, the user may set a ruleto control the length of time that the message and/or content isavailable to recipients. The user may set default rules that applyglobally or per new message and/or content sent, and the user may changethe rules at any time.

Note that all objects in the system are associated with permissions andrules, and embodiments of the present invention are not limited to theexample permissions and rules. When a device obtains or generates anobject, the device can determine the permissions and rules associatedwith the object and perform operations on the object or manage theobject in accordance with the object's permissions and rules. Forexample, message objects, stored content objects, and file attachmentobjects are all associated with permissions and rules and a device thatobtains or generates an object will comply with the permissions andrules associated with the object. Moreover, the entire messaging andcontent sharing system complies with permissions and rules set forobjects, and embodiments of the present invention are not limited to theexample objects.

Besides permissions and rules, the user can also delete a message acrossall devices. The user can send a message and then pull back the message.If the recipient forwards a message the user can choose to delete acrossall devices, including any forwarded messages, to pull back theforwarded message. By pulling back the message from a receiving device,the receiving device no longer has access to the message. Furthermore,when a user forwards a message, the system can guarantee that the userhas not modified the forwarded information in any way. The system maysecure a message so that the user may not tamper with the message whenforwarding the message to another user. A user can not manipulate orotherwise tamper with a message and then forward it to another userwithout others (e.g., the user receiving the forwarded message and/orthe sending user) knowing of the changes.

Sending Large Files

The system may also allow for sending large file attachments, such asterabyte-size attachments, by combining cloud storage with messaging.Current messaging systems are generally designed for storing and sendingtext messages, not binary files/objects or very large files/objects. Auser may send a large file through the messaging system without the userneeding to upload the large file to a storage service that can handlelarge files. The system may divide a large encrypted file into a smallportion that the system may send with the message and a large portionthat the system sends to a remote server for storage and access byothers.

The system may generate a link or reference to the large file or asignificant portion of the large file and include the link with themessage. The system may also generate a universal unique identifier forthe large file. Generally, the system may assign a universal uniqueidentifier to each object. The universal unique identifier is not tiedto any specific user. This facilitates storing links to content via adistributed hash table so that the content is not stored on a centralstorage point.

The system may send the universal unique identifier and the link to thereceiving device, and, in some embodiments, may also include a smallportion of the large file with the message. The system may send thelarge file to a server with the universal unique identifier.

The server may store data associating the file attachment with theunique identifier. The system may include a distributed hash tableimplemented across multiple servers to store the associations betweenthe unique identifier and stored data (e.g., the file attachment). Aserver may send the file attachment to any device that queries for datausing the unique identifier. For example, when a device receives amessage, the device obtains the unique identifier to retrieve the largefile attachment. The user on the receiving device does not need to knowthat the large file attachment was retrieved from a remote server (e.g.,a file storage service).

In some embodiments, the system may also provide an attachment-onlyview. When the user selects this view, the system hides the conversationportion and only displays attachments. The system may display multiplepictures of varying sizes that indicates to the user the contents of theattachments. The system may perform optical character recognition on theattachments to allow the user to search through the attachments. Theuser can scroll through a list of attachments to find what the user issearching for. The user can filter or sort the attachments in differentways, such as by date, filename, and/or sender name. The user may searchthrough metadata in attachments and also use Boolean logic to combinedifferent sorting and filtering conditions. For example, the user mayspecify to sort according to name and date. Further, eachfile/attachment may have a client-generated thumbnail for each file thatis very small in size and quick to transfer. This thumbnail may begenerated by a sending device. This provides the recipient a way to seea lower resolution preview of each picture, video (e.g., animatedpreview), Word document, etc. without having to download the originaldocument. The attachment view features may also include the ability orintelligence to search for content inside and around the files (e.g.,optical character recognition, meta data search, etc.) for advancedsearch and sorting. Note that current e-mail software requires the userto go through old e-mail messages to find attachments and this can bevery inconvenient and slow for a user since the user must click eachattachment to see the contents.

Note that the messaging and computing system described herein may beimplemented under a software as a service licensing and delivery model,and customers may license the software for the messaging and computingsystem on a subscription basis.

Sending Message and/or Content

FIG. 2 presents a flowchart illustrating a method for sending a messageand/or content to a recipient in accordance with an embodiment. Notethat different embodiments may vary according to detail and order ofoperations, and embodiments are not limited to the specific operationsdepicted in the figure. During operation, the sending device caninitially receive a message as inputted by the user. The system may alsoreceive content uploaded by the user or selected by the user (operation202). The system can also receive rules and permissions from the userfor the message and/or content (operation 204). The system can also usedefault rules and permissions for the message and/or content.

The sending device can then encrypt the message and/or content, whichmay include rules, permissions, a security object that includespermission and rule data, a unique identifier, and/or any other data(operation 206). The sending device can encrypt data using a symmetrickey, and then encrypt the symmetric key separately for each intendedrecipient using a recipient-specific public key. The sending devicesystem sends the encrypted symmetric keys to multiple devices. Therecipients of the encrypted symmetric keys can use their own private keyto decrypt and extract the symmetric key, and use the symmetric key todecrypt data sent from the sending device.

Generally, the system may encrypt all objects using a per-objectsymmetric encryption key, and the system encrypts the key for asymmetric key-encrypted object using asymmetric encryption. That is, thesending device need only encrypt an object once using a symmetric keyand then encrypt the symmetric key specifically for each recipient. Thesending device need not encrypt an object multiple times for differentrecipients. This saves time and is more efficient because some of theobjects may be large file attachments or content (e.g., 1 terabyte orlarger).

The system may use a different symmetric key for encrypting each objectand does not reuse a symmetric key to encrypt a different object. Forexample, the system uses a different symmetric key for encrypting eachof the message, the message attachment, a thumbnail attachment, and allother objects associated with the message. Thus, even if a maliciousparty may attack and compromise one symmetric key (e.g., for anattachment), the other symmetric keys remain intact (e.g., for otherobjects associated with the message).

The system can generate a universally unique identifier for identifyingdata or portions of the data. For example, the system (e.g., sendingdevice) may split a large file into two portions and generate a uniqueidentifier for the larger portion. The system may send the uniqueidentifier to a receiving device and the server. The unique identifierfunctions as a key to a distributed hash table. This distributed hashtable can be implemented over multiple servers. The distributed hashtable stores the association between the stored data and the uniqueidentifier. The receiving device can send a query with the uniqueidentifier to any server that implements the distributed hash tableand/or stores a copy of the data. Note that the unique identifier isoptionally stored via a distributed lookup table including but notlimited to a distributed hash table. The receiving device can retrievethe data from any number of servers since the data may be replicated andstored on multiple servers.

Next, the sending device can send a large encrypted (or unencrypted)portion of the message and/or content of a predetermined size to anenterprise server or a server in the cloud for storage (operation 208).For example, if the message includes a large file attachment, thesending device can encrypt the large file attachment, and split the file(encrypted or unencrypted) into two portions (e.g., the first 100 bytesof the file for small portion and the remainder of the file for thelarge portion). The sending device can then send the bigger portion ofthe file attachment to a server that the receiving device can retrievefrom. The system may retain the small portion of the data and store itlocally within a secure storage of the system, and, in some embodiments,can also include a copy of the small portion when sending a message.Without the small portion of the data, the receiving device (andmalicious attackers) may not be able to put together the complete set ofdata. In some embodiments, the sending device can split the encryptedfile (or an unencrypted file) into multiple portions that include morethan two portions, and the portions can vary in size. For example, therecan be many small pieces, one large and one small, one large and severalsmall, etc. Furthermore, the server may also send the entire encryptedlarge file attachment or content to a server.

The system may send a large portion of the encrypted (or unencrypted)file to a server that is one of many enterprise hardware devices withinan enterprise computing environment, or the server can be part of themessaging and computing system. In some embodiments, the system may alsoaccess a server of a cloud service (e.g., Dropbox or Google cloudstorage) on the Internet to send and store data.

The sending device may then send the message and/or content, which mayinclude rules, permissions, the unique identifier, the security object,the small portion of the encrypted (or unencrypted) file (or a link tothe small portion), and/or any other data to the receiving device(operation 210). In some embodiments, the sending device may sendcontact information, passwords, lists, and draft messages to otherusers, encrypted or unencrypted, and may revoke the information at alater time or based on a condition set by the user of the sendingdevice.

If the sending device receives a user command to perform an operation onthe message and/or content (operation 212), the sending device may sendthe command to the receiving device to execute the command (operation214). In some embodiments, the receiving device can also forward thecommand to other devices that have been forwarded the message.

In some implementations, the sending device may receive data from acomputing device indicating they received a copy of the forwardedmessage. The sending device may directly send the command to any devicethat has received a copy of the forwarded message. Devices that receivethe command may then comply with the command.

Receiving Message and/or Content

FIG. 3 presents a flowchart illustrating a method for receiving amessage and/or content in accordance with an embodiment. Note thatdifferent embodiments may vary according to order of operations, andembodiments are not limited to the specific operations depicted in thefigure.

A receiving device may initially receive the message and/or content(operation 302). The receiving device may receive the message and/orcontent from a device that originally sent the message and/or content,or from a device that forwarded the message and/or content. Thereceiving device may receive the message via a messaging server. Themessage and/or content may be encrypted (or unencrypted) and thereceiving device may decrypt and/or extract various data from themessage and/or content received. This data may include one or more ofrules, permissions, a universally unique identifier, a link to asubstantial portion of an encrypted (or unencrypted) large fileattachment or content stored on a remote server, a small portion of theencrypted (or unencrypted) large file attachment or content (e.g., asmall .zip file), a security object, and/or any other data included withthe message (operation 304). In some embodiments, the receiving devicemay receive a link to a small portion of a large file attachment orother content, and query a server for the small portion rather thanreceive the small portion with the message.

The receiving device may obtain additional data from a server if themessage and/or content indicates that a portion of a large encrypted (orunencrypted) file is stored elsewhere (operation 306). For example, ifthe message includes a large file attachment, then the receiving devicemay retrieve a large encrypted (or unencrypted) portion of the fileattachment from a remote server. The receiving device sends the uniqueidentifier to one or more servers over the network and then receives thecorresponding data back from a server. The receiving device can retrievethe stored data (e.g., large file attachment or other content) from anyone of multiple servers that replicate the additional data. Thereceiving device may then combine together the split portions of thelarge file attachment or content. If the receiving device cansuccessfully decrypt an entire encrypted file, then the receiving devicehas obtained the correct data. For example, if the portions areencrypted, then the full encrypted file is a combination of an encryptedpiece and an encrypted remainder. The full encrypted file can then bedecrypted using the symmetric key whereas the encrypted piece orencrypted remainder would fail to decrypt independent of each other. Thebig portion (e.g., remainder file) may be publicly available on Dropbox,a web server, etc. A diff file (e.g., a much smaller portion) may besecurely transmitted or stored somewhere. The receiving device may applythe diff file to the remainder file to generate a file equal to theoriginal file (encrypted or not). Note that in some scenarios, a devicemay combine together portions of an unencrypted file.

Note that multiple servers may implement a distributed hash tablestoring associations between the universally unique identifier andobjects such as file attachments or content. The unique identifier mayfunction as a lookup key for the distributed hash table. The servers canlook up the distributed hash table to identify the correct object toreturn to a device that submits a query using a corresponding uniqueidentifier.

The distributed hash table may also store public keys for users orreceiving devices, so that a sending device can request a public key forany potential recipient. The sending device can obtain public keys formultiple recipients, and may send each recipient the same symmetric keybut the symmetric key is encrypted using each recipient's specificpublic key. Each recipient can decrypt and extract the symmetric keyusing their own specific private key.

Since the stored data is replicated and distributed on differentservers, there are multiple ways in which the receiving device canobtain the stored data. In some embodiments, the receiving device canattempt to retrieve the stored data by sending a query with the uniqueidentifier key to a local hardware device or an enterprise computingdevice. The local hardware device may return the data or may provide thereceiving device with information on servers that store the data andtheir respective download speeds, including which servers providefastest download speed. The receiving device can attempt to retrieve thestored data by submitting a query to servers with access to thedistributed hash table and/or stored copies of the data, and receivingdata from a server that is known to be trusted. The receiving device canalso retrieve data by sending the query with the unique identifier keyto a server that is part of the messaging and communication system(e.g., the software as a service). In some cases it may be faster forthe receiving device to access an enterprise hardware device to retrievedata over a local area network but if the receiving device does not haveaccess to the enterprise hardware device, then the receiving device canaccess the data from the software as a service.

The receiving device may then display the message or otherwise make thecontent available to the user of the receiving device (operation 308).

If the receiving device receives user input indicating an operation onthe message and/or content (operation 310), the receiving device maydetermine whether the operation is authorized based on the rules andpermissions (operation 312). If the operation is authorized, then thereceiving device may execute the operation on the message and/or content(operation 314). The receiving device continues to manage the messageand/or content while complying with the rules and permissions (operation316). For example, the receiving device may determine when to delete anobject based on a rule associated with the object. As another example,the receiving device may receive subsequent requests to performoperations on the message and/or content and the receiving device mayonly perform such operations when authorized by the permissions andrules.

Anonymously Accessing External Service

FIG. 4 presents a flowchart illustrating a method for anonymouslyaccessing an external service in accordance with an embodiment. Notethat different embodiments may vary according to order of operations,and embodiments are not limited to the specific operations depicted inthe figure. Further, some embodiments may execute the process of FIG. 4entirely on a mobile device, while in other embodiments, a mobile devicemay use a server to anonymously access external services.

The system may include a zero-login feature that allows a user to addand use an external service, such as a social networking service,without logging in to the external service. The external service can beany service provider, such as Twitter or an SMS text messaging serviceprovider. The system acts as a proxy to allow the user to anonymouslyaccess the external services. For example, the user can anonymously usethe social networking service to contact (e.g., e-mail or text message)or send data to others until the user wants to authenticate his identitywith the social networking service. The system provides the user with ananonymous user ID and the user only needs to indicate the identity ofthe other party that the user wants to communicate with. The other partysees the message coming from the anonymous user ID. In one embodiment,the receiving party receives a message with a link, and the messageinforms the receiving party that an anonymous user is trying tocommunicate with the receiving party or send a file to the receivingparty. The receiving party may then click the link to view the messageor obtain the file.

In some embodiments, the user can authenticate himself to the systemusing a login associated with an external service, such as an e-mailaddress, a Twitter account, or a Facebook account. The system can verifythat the user owns the login account on the external service. The systemcan also verify how other users can message the user via the externalservice using the login (e.g., e-mail address, SMS number, social username, etc.). After the user authenticates himself for a particularexternal service, the system may reveal the true identity of the user onthe external service to the recipients of anonymous communicationsand/or other data from the user. After the user's identity is revealed,the user would directly receive messages and content data from otherusers on the external service.

During a zero-login process, the system may initially receive a userselection of an external service and user entry of a message and/orcontent (operation 402). The user may also select content from his localdevice or on a network. The system may then send the user communicationand/or content as an anonymous user to the external service (operation404). For example, the system may send the message “how are you?” toanother user on a social networking service. The other user will receivethe message but without any information identifying who was the sender.

The system may then receive user input verifying the user's identity fora particular external service (operation 406). The system may verify theuser identity with the external service. The system may then use theverified user identity for the external service (operation 408).

Setting Rules for New Message

FIG. 5 presents an illustration of a screen that allows a user to setrules for a new message in accordance with an embodiment. As illustratedin FIG. 5, a screen 500 displays a new message text entry area 502. Themessage is addressed to a recipient Lisa. The user can set when thesystem will delete the message. On the depicted screen the user hasadjusted the “delete after” setting 504 so that the system (e.g., areceiving device) will delete the message after a receiving party firstviews the message. Also, the user can adjust a “delete after ascreenshot” switch 506 (e.g., currently enabled) so that the system willdelete the message after the receiving device takes a screenshot of themessage. The user can also adjust a “notify after a screenshot” switch508 so that the sending party is notified of any screenshots taken byreceiving parties. On the depicted screen, switch 508 is set to adisabled position so the sending party is not notified of screenshotstaken by receiving parties. The system includes a setting 510 thatallows the user to select whether the rules apply to all recipients or aselection of recipients.

Change Permissions on Recipients of New Message

FIG. 6 presents an illustration of a screen that allows a user to changepermissions on all recipients of a new message in accordance with anembodiment. As illustrated in FIG. 6, a screen 600 displays a messagetext entry area 602. The message is addressed to a recipient Lisa. Theuser can adjust a forwarding switch 604 (e.g., currently enabled) toallow other users to forward the message, and can adjust a stashingswitch 606 (e.g., currently enabled) to allow other users to stash(e.g., archive or move to a folder for storage and/or classification)the message.

A stash is also a location synchronized across all user devices formessage drafts, uploaded files, notes, passwords, objects etc. that maybe then sent or shared via the platform. The stash may function as avirtual hard drive. Stash allows the user to save versioned objects ofall types to the distributed system for later viewing, sharing,collaboration and group editing, and sending. A user can put his itemsin stash to have it appear on all of the user's other devices.Everything stored with stash may be encrypted. Only the user and thepeople that the user specifies may view/edit, etc. and have the power toroll back to old versions, view thumbnails (e.g., similar to theattachment view), and search/sort in a manner similar to messages andattachments. Some examples of stash features include but are not limitedto message drafts, files, and notes.

Message drafts—these are messages a user started to compose and wishesto resume editing on a different device or pass off to a different userto edit. The message draft may or may not be encrypted, and the senderand any shared viewers/editors may be given various levels ofpermissions to access the message draft. Multiple versions can be savedand rolled back, and the user can view the differences between versions,etc. Some embodiments can also support files that have been uploaded tothe system and attached but not sent.

Files—this is a very safe and secure file hosting service. A user canupload one-to-many files and folders, assign permissions on who canview/access/edit, assign tags to classify a file, and set reminders toperform some action on the file. Some embodiments may also support allversioning features, roll back viewable differences, etc.

Notes—includes, but is not limited to, free form text, pictures, video,Global Positioning System (GPS) location, maps, voice, etc. withnote-taking capability. Users can tag, attach files, assign permissions,set reminders, and use versioning capability.

The user can also adjust a switch 608 to allow other users to addparticipants (e.g., currently disabled), and can adjust a “removingparticipants” switch 610 (e.g., currently enabled) to allow other usersto remove participants. Note that the user can also change permissionsfor a single recipient or any set of recipients. Other examples ofpermissions include but are not limited to printing, selecting text, andexternal downloading.

Hierarchical Display of Group Messages

FIG. 7 presents an illustration of a screen that shows an exemplaryhierarchical display of group messages in accordance with an embodiment.The system may also include a hierarchical structure and hierarchicaldisplay for group messaging. The system manages and stores groupmessaging data using a hierarchical structure. This hierarchical displayutilizes a tree structure to illustrate the threads of a conversationwhen multiple users are communicating with each other. The user may theneasily follow the threads of the group conversation and see who isresponding to whom in the conversation. Existing group messagingsoftware typically only displays a scrolling interface that displayseach message as a user sends out the message. It is difficult for a userto follow the different threads of a group conversation with existinggroup messaging software.

As illustrated in FIG. 7, a screen 700 displays a group messagingsession between users Rey, Henry, and Brian. The three users arerepresented in the users panel display 702. The messages in the groupmessaging session can be organized in a hierarchical display. Thishierarchical display resembles a tree structure that allows the user toeasily follow the conversation threads, since replies to a message aredisplayed as nested within (e.g., branching off from) the message.

A picture or other user icon (e.g., pictures 704 a, 704 b, 704 c, 704 d)depicting each user and a corresponding message may be indented withinscreen area 706 to show responses to Henry's question. For example, theuser can more easily follow the responses to Henry's question (e.g.,“Chipotle?”) since the responses in screen area 706 are indented to showthat the responses are nested within the original question. In someimplementations, the screen area 706 may be shaded with light greyhighlight or some other shading or color to indicate responses toHenry's question. A message input box 708 allows a user to input aquestion to send to participants in the messaging group (e.g., “Howabout wings?”).

In some implementations, a user may click on a reply message in aconversation thread to cause the system to display the original messagethat the reply message is directed at. For example, a user may click ona message display box 710 displaying “Sounds good” and then the systemwill pop-up and display the original message that started the thread(e.g., “Chipotle?”). The system may display the pop-up visual indicatorindicating the content and sender for the message “Chipotle?” thatstarted the thread. The system may also respond to the user clicking onthe pop-up visual indicator by navigating to the original message“Chipotle?” and graying out the reply messages in the thread. This makesit easier to navigate business-oriented threads with a large number ofmessages. Some embodiments may also display a fork in a thread when auser forwards a message.

FIG. 8 illustrates an exemplary computer system that facilitates amessaging and content sharing platform with sender-controlled securityin accordance with an embodiment. In this example, a system 800 formessaging and content sharing can include but is not limited to aprocessor 802, a memory device 804, and a storage device 806. System 800may optionally include a display module 808, an input module 810, and acommunication module 812. In some embodiments, system 800 may beimplemented on a mobile device, and in other embodiments, one or morecomponents of system 800 may also be implemented on another computingdevice, such as a server.

Storage device 806 can store instructions which when loaded into memory804 and executed by processor 802 cause processor 802 to perform theaforementioned operations (e.g., for a sending device or a receivingdevice). More specifically, the instructions stored in storage device806 can include an encryption/decryption module 814, a security module816, and an identity management module 818.

Encryption/decryption module 814 encrypts and decrypts objects such asmessages, attachments, and other content objects. Security module 816manages the rules and permissions associated with objects. Identitymanagement module 818 verifies the identity of the user. It can verifythe identity of the user with external services such Twitter, e-mail,and Facebook. Identity management module 818 can also act as a proxy forthe user when the user seeks to use external services anonymously. Insome embodiments, identity management module 818 may be implemented on aserver, and a mobile device may interact with a server executingidentity management module 818 to access external services anonymously.

Delivering Secure Messages Over Unsecured Channels

The relentless growth of the Internet has brought with it an everincreasing demand for applications that facilitate to conduct varioustypes of transactions online. Secure communications, among other things,are becoming progressively important to service providers. Over the pastfew decades, a number of systems for delivering secure messages overunsecured channels have been developed. For example, there exist anumber of public key infrastructure (PKI) systems that can issue digitalcertificates which facilitate two communicating entities to encrypttheir messages.

Simply encrypting messages, however, might not be sufficient. Forexample, even when messages (such as emails) are encrypted between twocommunicating entities, the cipher text is often transmitted over anopen, unsecured channel, and the sending and receiving parties'identities are also known to the public. Such information can be used bya malicious user to decrypt the cipher text (for example, by usingbrute-force dictionary-based cracking methods).

In many situations it is desirable to obscure secure communicationsbetween a sender and a recipient with a cover message. Traditionally,the cover message has been manually generated, typically by the senderor on the sender's behalf. The cover message might be based on atemplate or form, with a customized salutation or address specific tothe recipient. The manual process is time-consuming and may requirepersonal knowledge by the sender of context relevant to the recipientfor the cover message to appear personal. Other automated cover-messagegeneration methods are often impersonal and the messages generated areeasy to spot as form or bulk cover messages.

Controlling Access to Encrypted Data

Embodiments of the present invention also provide an access-controldevice (hardware box) that solves the problem of protecting an entity'sonline communication and shared documents from being accessed byunauthorized entities. Using the access-control device, a user cancommunicate over a messaging framework (e.g., via email, a short messageservice (SMS), or an instant messaging service, etc.) or in-real timeover a voice line (e.g., VoIP) using encrypted messages, and theaccess-control device can ensure that only authorized entities are ableto decrypt the encrypted messages.

Moreover, the user can communicate over an existing third-party onlinesocial-media service, such as Twitter or Facebook, and theaccess-control device can ensure that only other authorized entities canview the protected content posted by the user. The access-control devicecan secure the content from eavesdroppers, such as the third-partyonline service itself, or any malicious entity that gains illegitimateaccess to the third party service's servers.

Hence, the access-control device can function as a user add-on to anyexisting online service, to protect the user's communication over thatonline service. For example, when communicating over email or an instantmessaging service, a local user can generate a message that includes afile or document as an attachment. In some embodiments, theaccess-control device can generate a new message that includes a benignstatement and/or benign attachment in plaintext (un-encrypted) form that“masks” or “cloaks” the user's protected content, and can include theattachment in encrypted form (or can include a link to the encryptedcontent). This benign content is meant to distract an eavesdropper fromthe protected content by satisfying the eavesdropper's curiosity, andhiding the fact that the message includes an attachment. If theeavesdropper does not become aware of the protected content, theeavesdropper may not be motivated to crack the decryption of theprotected content.

Hence, the access-control device allows the user to communicate withothers over existing communication platforms that are typicallyimplemented in a client-server architecture, while also protecting theuser's communication. The user's client computer can generate and send amessage to the server, and the server can send the message to a specificclient that is authorized to access the content (e.g., via a pushtransaction, or in response to a pull request), or can publish thecontent for multiple clients to access. The access-control device canreside anywhere in the computer network between the user's clientcomputer and the third-party server. In some embodiments, theaccess-control device can be a network switch, router, or firewall for asecure local area network (LAN). Alternatively, the user can configurehis client computer or a router to use the access-control device as aproxy server for the client computer.

Exemplary Network Environment

FIG. 9 illustrates an exemplary network environment 900 that facilitatesprotecting a user's communications over a computer network in accordancewith an embodiment. Network environment 900 can include a computernetwork 902, which can include any wired or wireless network thatinterfaces various computing devices to each other, such as a computernetwork implemented via one or more technologies (e.g., Bluetooth,Wi-Fi, cellular, Ethernet, fiber-optic, etc.). In some embodiments,network 902 includes the Internet.

Network environment 900 can also include a computing device 904, which auser 906 uses to communicate a message or data to another user 912 orhis computing device 910. During communication, one computer typicallyneeds to send data to another computer, oftentimes using a large datafile or data stream. For example, data for a conference call can includean audio stream and/or a video stream. Sometimes the communication caninclude additional data that may aid the communication, such as apresentation slide or deck, a webcast, a document, etc.

Computing device 904 can be a smartphone 904.1, a personal computer904.m, or any device that needs to send or publish data over network902. In some embodiments, user 906 can assign an access-control device908 to computing device 904, which computing device 904 can use toprotect the local user's data from being accessed by unauthorizedentities. Similarly, user 912 can assign an access-control device 914 tocomputing device 910.

In some embodiments, access-control devices 908 and 914 can be membersof a distributed hash table (or block chain) that can store digests forcover messages generated by any sending device. By storing these covermessage digests, access-control devices 908 and 914 can confirm whethera benign message received by a receiving device is in fact a covermessage. In one embodiment, a receiving device can send a benign messagedigest to access-control device 908 or access-control device 914, whichin turn can compare the received digest with its stored digests todetermine whether the benign message is a cover message or just aregular benign message.

Access-control device 908 can sit between computing device 904 and amessaging server 916 which computing device 904 uses to communicate withuser 912. One advantage of this configuration is that messaging server916 can speed up the transmission process between computing device 904and computing device 910. Another advantage is that access-controldevice 908 can act as a repository for keys to the communication data,and computing device 904 only sends a portion of the encryptedcommunication message to data message server 916. Computing device 904can leave a small percentage of the encrypted message on access-controldevice 908 itself. For example, when computing device 904 needs to senda message, computing device 904 may first encrypt the message locally,and extracts a portion of the encrypted message (e.g., 99%) to produce acorrupt version of the encrypted message. Computing device 904 may thentransmit the corrupted encrypted message to message server 916, andtransmits an access key that includes the extracted portion toaccess-control device 908. Hence, even though message server 916receives the encrypted messages, message server 908 does not have allthe data that is necessary to make use of these encrypted messages.

Topic server 918 can be responsible for collecting topics from anydevice in the network. In one embodiment, topic server 918 candistribute to the devices a generic topic list. Such a list might bebased on, for example, the current popular topics in the news, sports,entertainment industry, etc. A respective device may download thisgeneric list from topic server 918. In addition, the device may performdata mining on the user's local contextual data, such as the user'semails, calendar entries, chat history, text message history, webbrowsing history, etc., to determine whether a topic in the generictopic list is relevant to the user. In addition, the device can send arelevant topic list, which contains all the pertinent topics based onthe user's contextual information, to topic server 918. In turn, topicserver 918 can store each user's relevant topics. In one embodiment, arespective relevant topic list may be indexed by the correspondinguser's identifier. Such an identifier can be a phone number, an emailaddress, a social network media ID, or a globally unique identifier thattopic server 918 generates for the user.

A remote computing device 910 associated with the intended recipientuser 912 can obtain the encrypted message by first determining whichpieces of data need to be received for the user by issuing a request totopic server 918. Topic server 918 can return a list of messages thatcomputing device 910 may have in common with computing device 904. Atthis point, computing device 910 can issue a request to data messageserver 916 to obtain the corrupt encrypted message, and can issue arequest to access-control device 908 to obtain an access key thattransforms the corrupt encrypted message into the original encryptedmessage. In some embodiments, the key can include the data segments thatcomputing device 904 extracted from the original encrypted message toproduce the corrupt encrypted message.

One major advantage to this communication approach is that the sendingdevice (e.g., computing device 904) can use any messaging server with ahigh network bandwidth to send or distribute a message or file to one ormore recipients, without risking the data becoming compromised or leakedvia these messaging servers. The access-control device can remain in thesender's possession (e.g., within an at-home local area network (LAN)),and may only need to send a small portion of the message or file (e.g.,1%) to the intended recipients via the user's own wide area network(WAN) connection.

Another major advantage to this approach is that it becomes impossiblefor a malicious entity to decrypt the sending device's messages,regardless of how much computing power the malicious entity uses toattempt to decrypt the sending device's data stored on the messageserver. While it is virtually impossible to decrypt a message that isencrypted using a large encryption key using modern computers, it maybecome possible to decrypt this encrypted content in the near futurewith future computing technologies. For example, advances in quantumcomputing threatens to undermine the security of modern encryptiontechnologies by having the quantum computer attempt all possible (or asignificant percentage thereof) encryption keys at once to decrypt apiece of encrypted content.

However, because the access-control device can retain key segments ofthe encrypted data, and the user can be in possession of theaccess-control device, the user in essence may retain complete controlover his encrypted data. Therefore, because a malicious entity is notable to get a hold of the extracted segments of the encrypted data, themalicious entity may not have all the information necessary to evenbegin the decryption process. If the malicious entity were to attempt todecrypt the modified encrypted data with the valid decryption key, themalicious entity may only obtain a corrupted message that does notreveal any information of the original plaintext message.

In some embodiments, the sending device can push the message (or a largeportion of the message) to each intended recipient ahead of time,without having to first receive a request for this message from therecipients. This allows the message to become available at therecipients' devices before they even become aware of the message, andallows them to quickly access large messages (e.g., multi-gigabyte videostreams) without having to first request and download the message. Whena recipient wishes to consume the message, the recipient's computer canissue a request for the remaining small portion of the message (e.g., akey containing 1% of the message), at which point the recipient's devicedownloads the remaining small portion and uses this portion toreconstruct the original message.

In some embodiments, the extracted portions of message data retained bythe access-control device (and not sent to the message server) isdetermined based on a minimum amount of data and locations of the datathat, if missing, would render it impossible to decypher anycomprehensible data from the remaining portions of the data. Forexample, the system can determine an amount of data to extract based ona size of an encrypted file or message. Also, the system may determinewhich strategic locations of the file are to be used to extract theportions of the file based on the type of data (e.g., an audio or videostream, or a document), the type of encoding (e.g., size of data chunksfor a data stream), and/or the encryption algorithm used.

For example, if the encrypted data is a data stream that is encoded andencrypted in segments, the minimum amount of data that needs to beremoved from the encrypted data may correspond to the individualsegments of the encrypted data stream. If the segments are 1 MB(megabytes) in size, the system may extract a 1 KB (kilobyte) portionfrom each 1 MB (megabyte) segment, to render the new segments corruptedand unreadable. If the data stream is encoded into variable-sizesegments, the location and portion of the encrypted data stream fromwhich the system extracts data may vary according to the location andsize of each segment in the encrypted data stream.

In some further embodiments, the system can vary the location of eachencrypted data stream segment that is used to extract data, to prevent amalicious entity from performing a predictive attack. For example, thesystem can decide on which portion is to be extracted at runtime whilegenerating the corrupted version of the encrypted data stream. Also, thesystem can store the segment number and byte offset of the extractedportion, along with the extracted portion, in the access-control device.Then, when an authorized receiving entity requests the extractedportion, the access-control device can return the extracted portion,along with a patch that the recipient can apply to the binary datastream (corrupt data) to recreate a segment of the encrypted datastream. The patch may include, for example, instructions that specify astream timestamp or byte offset, or specify a stream segment number anda byte offset, that the receiving device can use to insert the extractedportion into the binary data stream to recreate the segment of theencrypted data stream.

Note that, although the exemplary network environment illustrated inFIG. 9 includes a message server 916 and a topic server 918 as separatesystems (which might or might not be located in different locations),these servers can also reside in a common hardware system or datacenter.In one embodiment, the functions of these two servers can be carried outby a common physical server.

FIG. 10 presents a time-space diagram illustrating an exemplary processfor automatically generating context-aware cover messages in accordancewith an embodiment. In this example, assume that a sending device 1002needs to send a secure message to a receiving device 1004, and that apublic/private key pair has already been distributed between sendingdevice 1002 and receiving device 1004. During operation, sending devicemay 1002 first encrypt the secure message with receiving device 1004'spublic key (operation 1020), and may generate a partial message thatincludes a corrupted version of the secure message by extracting one ormore segments of the secure message. Sending device 1002 may thengenerate an access key that includes the one or more extracted segmentsof the secure message.

Sending device 1002 then sends corrupted message 1022 (e.g., a partialmessage) to a message server 1006, and sends the access key toaccess-control device 1009. At approximately the same time, sendingdevice 1002 may send a topic request 1024 to a topic server 1008. Thepurpose of sending topic request 1024 is to obtain a list of commontopics shared between sending device 1002 and receiving device 1004. Inone embodiment, topic request 1024 can include an identifier for sendingdevice 1002 and an identifier for receiving device 1004.

In response topic request 1024, topic server 1008 can send a sharedtopic list 1026 to sending device 1002. Note that shared topic list 1026can include any topic that is relevant to the respective users ofsending device 1002 and receiving device 1004. For example, shared topiclist 1026 might include latest news of a local sports team, a recentlyreleased film, popular news topics, popular music, etc.

After receiving shared topic list 1026, sending device 1002 can author acover message (operation 1028). To author the cover message, sendingdevice 1002 can select one topic from topic list 1026, and canautomatically generate a piece of content based on the selected topic.Various methods can be used to generate the content, which can be acombination of text, pictures, and other medium form. In one embodiment,sending device can issue a search to the Internet with the selectedtopic as a search key word, and crawl the search results to generate thecontent.

Subsequently, sending device 1002 can generate a cover message digest1030, for example, by computing a hash value of the cover message.Sending device 1002 may then send cover message digest 1030 toaccess-control device 1009, which in turn may store cover message digest1030. Recall that access-control device 1009 can implement a distributedhash table with one or more other access-control devices. In someembodiments, access-control device 1009 can synchronize the local hashvalues (or block chain) with one or more other access-control devices,such as an access-control device 1010 associated with receiving device1004.

Furthermore, sending device 1002 can deliver or post the cover message(operation 1032). Note that the cover message can be delivered toreceiving device 1004 in various ways. For example, the cover messagecan be sent as an SMS message, an email, a blog post, a social networkmedia entry (such as a Twitter or Facebook entry). The user of sendingdevice 1002 can set a preference for the delivery of the cover message,or can select a delivery medium at the time the user generates and sendsthe message.

In some embodiments, access-control device 1009 can author cover message1028 and deliver/post cover message 1032 on behalf of sending device1002.

In response, receiving device 1004 can receive or detect the covermessage (operation 1034). In one embodiment, receiving device 1004 maybe pre-configured to monitor certain communication channel(s), such asSMS messages, incoming emails, a certain blog, or a certain socialnetwork media channel. Once the cover message is received, receivingdevice 1004 may compute a hash for the cover message to produce covermessage digest 1036. Next, receiving device 1004 can send cover messagedigest 1036 to cover message server 1010, which can search its storageto determine whether cover message digest 1036 matches with anypreviously stored digest. Cover message server 1010 may then send anacknowledgement 1038 back to receiving device 1004 to confirm whethercover message digest 1036 indicates that receiving device 1004 has infact received a real cover message, instead of a regular benign message.

After confirming that the cover message indicates the availability of asecure message for receiving device 1004, receiving device 1004 maysubsequently send a request 1040 to message server 1006 to requestcorrupted message 1022, and may send a request 1041 to access-controldevice 1009 to request access key 1021. Note that receiving device 1004may be required to authenticate itself with necessary securitycredentials (such as a password or a digital certificate), either priorto or along with request 1040 and request 1041. In addition, request1040 and request 1041 can include receiving device 1004's identifier,which message server 1006 may use to locate corrupted message 1022, andwhich access-control device 1009 may use to local access key 1021. Inresponse to receiving a valid request 1040, secure message server 1006may transmit encrypted message 1022 to receiving device 1004. Also, inresponse to receiving a valid request 1041, access-control device 1009may transmit access key 1021 to receiving device 1004. Receiving device1004 may then use the corrupt encrypted message 1022 and access key 1021to recreate encrypted message (operation 1041), and may then proceed todecrypt encrypted message 1041 using its private key (operation 1042).

Sending Device

FIG. 11 presents a flowchart illustrating a method for automaticallygenerating a context-aware cover message in accordance with anembodiment. During operation, the sending device can receive a securemessage from the user (operation 1102), and can encrypt the securemessage based on a previously distributed key pair (e.g., the receivingdevice's public key) (operation 1104).

Next, the sending device can extract at least one portion of theencrypted message to produce a corrupted message (operation 1106), andcan generate an access key that includes the at least one extractedportion of the encrypted message (operation 1108). The sending devicemay then transmit the corrupted message to the message serve or to thereceiving device (operation 1110), and may transmit the access key tothe local access-control device (operation 1112).

Subsequently, the sending device can request and receive a list ofcommon topics shared with the receiving device from the topic server(operation 1114). The sending device can then author a cover messagebased on one or more topics shared with the receiving device (operation1116). The sending device can also hash the cover message to produce adigest (operation 1118), and can transmit the cover message digest tothe cover message server (operation 1120). The system can use varioushashing methods, such as SHA-512. Next, the sending device may deliverthe cover message (operation 1122). In some embodiments, the covermessage can be delivered by a third party, instead of by the sendingdevice.

FIG. 12 presents a flowchart illustrating a method for uploading, to atopic server, a list of topics relevant to local context in accordancewith an embodiment. In general, a sending or receiving device may firstreceive a generic topic list from the topic server (operation 1202).Note that the topic server can regularly search the Internet to compilethe generic topic list. The device may then collect local contextualdata (operation 1204), such as by scanning the local user's emails, SMSmessages, chat history, blog entries, social media content history, webbrowsing history, etc. Next, the device can filter the generic topiclist based on the local contextual data (operation 1206). The device maysubsequently transmit the filtered topic list back to the topic server(operation 1208).

Access-Control Device

FIG. 13 presents a flowchart illustrating a method for creating a blockchain entry for a secure message in accordance with an embodiment.During operation, an access-control device can receive an access key fora corrupted message from a sending device (operation 1302), and receivesa cover message digest associated with the corrupted message (operation1304). The access-control device then stores the access key inassociation with the cover message digest (operation 1306). For example,the access-control device can store the access key in a lookup table orrelational database, using the cover message digest as the index for theaccess key.

In some embodiments, the access-control device uses a block chain tostore the cover message digests. Also, the access-control device can bea member of a distributed hash table that is implemented across aplurality of access-control devices. Hence, the access-control devicecan add the cover message digest to the local block chain (operation1308). The access-control device also determines whether the localaccess-control device is a member of a distributed hash table (operation1310). If so, the local access-control device can synchronize the localblock chain with one or more other boxes of the distributed hash table(operation 1312).

Receiving Device

FIG. 14 presents a flowchart illustrating a method for receiving a covermessage and obtaining a corresponding secure message in accordance withan embodiment. During operation, a receiving device can detect orreceive a benign message by monitoring one or more communicationchannels (operation 1402). The receiving device computes a hash of thebenign message to produce a benign message digest (operation 1404). Notethat some hashing methods (such as the SHA-512 hashing method) can becomputationally expensive on a general-purpose processor.

In some embodiments, a dedicated, special-purpose piece of hardware(such as an application-specific integrated circuit (ASIC) or fieldprogrammable logic array (FPGA)) is used to perform the hashingfunction. The receiving device then queries the access-control devicewith the computed digest (operation 1406). Based on the response fromthe cover message server, the receiving device determines whether thebenign message is a cover message (operation 1408). If the benignmessage is not a cover message, the receiving device does not performany special operation.

If the benign message is a cover message, the receiving devicedetermines whether the corrupted message is already stored locally(operation 1409). If the corrupted message is not stored locally, thereceiving device may download the corrupted message from the messageserver using its existing security credentials (operation 1410), anddownloads the access key from the sender's access-control device usingthe existing security credentials (operation 1412). In some embodiments,the sending device may push the corrupted message directly to thereceiving device. The receiving device does not need to download thecorrupted message at the time the user wishes to view the message.Hence, if the corrupted message is already stored locally, the receivingdevice can proceed to operation 1412 to download the access key withoutfirst having to request or download the corrupted message.

Recall that the access key can include one or more data portions thatwere extracted from an encrypted message to produce the corruptedmessage. The receiving device can create the encrypted message from thecorrupted message and the access key (operation 1414), and can decryptthe encrypted message using its private key (operation 1416).

In some embodiments, the receiving device can also be configured to usean access-control device to receive and cache data being transmitted bythe sending device. For example, the access-control device associatedwith the receiving device can obtain the corrupted encrypted data, canrequest and receive the extracted portions of the encrypted data, andcan re-insert the extracted portions into the corrupted encrypted datato recreate the original encrypted data on behalf of the receivingdevice.

Moreover, the receiving device's access-control device can obtain andcache (or store) the recreated encrypted data ahead of time, so that theencrypted data is available for the receiving device when the receivingdevice requests the encrypted data. For example, the message server, thesending device, or the sending device's access-control device can pushthe corrupted message to the receiving device's access-control device.The receiving device's access-control device can recreate the encrypteddata upon receiving the push message.

As another example, the receiving device's access-control device canpre-fetch data from a third-party online service, such as an emailserver, an on-line social media service (e.g., Twitter, Facebook, etc.).In some embodiments, one or more message servers implement thethird-party online service. In some other embodiments, the messageserver can host encrypted data that is being transferred along with (and“masked” by) a message published via the third-party online service.When the receiving device's access-control device receives a corruptedmessage from the message server, the access-control device can determinea network address for another access-control device associated with thecorrupted message (e.g., the sending device's access-control device),and can issue a request to this network address to obtain the access keyor the extracted portion of the corrupted message.

Furthermore, the receiving device can also be configured to use anaccess-control device to protect data published or transmitted by thereceiving device. For example, a local user and a remote user canimplement secure two-way communication by each configuring anaccess-control device to secure data on behalf of the user. Anaccess-control device that is managed by the local user can storeextracted portions of the local user's data (e.g., 1% of the data), andcan provide these extracted portions to the remote user's device uponrequest. Similarly, an access-control device that is managed by theremote user can store extracted portions of the remote user's data, andprovides these extracted portions to the local user's device uponrequest. This provides two advantages to the two-way communication:communication becomes secure and only accessible to the local and remoteusers; and the computational overhead of securing their communication isoffloaded to the two access-control devices that may have morecomputational and energy resources than the personal computing devicesused by the local and remote users.

Distributed Framework

In some embodiments, a plurality of access-control devices can cooperateto form a distributed framework that can store data in encrypted formfor a user, and can validate the authenticity of each other's storeddata. Moreover, the access-control devices of the distributed frameworkcan store cove message digests for messages that have been madeaccessible to a receiving device.

In some embodiments, a cover message digest is a “hash code” that pairswith a piece of encrypted message. For example, the distributedframework can group one or more cover message digests into a “block”that is stored across the access-control devices in the distributedframework, such that each block includes a set of validated covermessage digests. Moreover, the blocks stored in the distributedframework can be block chained, so that each block in the block chainincludes a digest (e.g., a hash value) for the next block in the blockchain. Storing the cover message digests as a distributed block chaincan allow tampered blocks to be detected. For example, if a maliciousentity were to tamper with a block in one access-control device, theaccess-control device can determine that the block has been tamperedwith by comparing the block's hash value with the hash value stored inthe previous block of the block chain. The access-control device canperform a remedial action, for example, by requesting a validated copyof the block from other access-control devices of the distributedframework, and replacing the tampered-with block with the validatedcopy.

Moreover, other access-control devices of the distributed framework candetect the tampered-with block by comparing its hash value with that ofthe other access-control devices in the framework. The distributedframework can also perform a remedial action, such as by removing thetampered-with access-control device from the distributed framework.

In some embodiments, the distributed framework can includeaccess-control devices owned or managed by a plurality of individualusers or organizations. The security of the distributed framework canincrease as more access-control devices and more trustworthy entitiesjoin the distributed framework.

In some other embodiments, a single organization or entity can create aproprietary distributed framework by configuring a plurality of personalaccess-control devices to implement a distributed hash table or blockchain amongst themselves, without allowing an access-control device thatis not owned by the entity to join the distributed framework. Theaccess-control devices that are within the distributed framework mayreside within a secure local area network (LAN) or virtual privatenetwork (VPN) that is secured and managed by the organization or entity.For example, the organization may deploy multiple access-control devicesat each office building that is owned or managed by the organization,and can configure the proprietary distributed framework to secure allcommunication performed by any member or employee of the organization.

This ensures that all communication performed by the organization'smembers can be validated during the communication event. For example,the distributed framework can validate all real-time communication(e.g., a voice or video conference call) by ensuring that onlyauthorized receiving devices can listen in on the communication. Asanother example, the distributed framework can track email messages sentto other entities, and can validate a request to read an email messagebody from a receiving device that received a corrupted version of theemail message. Moreover, the organization can modify a list ofrecipients for an already-sent message, for example, by rejecting arequest for the extracted portion of a message when a recipient has beenremoved from the list of allowed recipients, or when the message isbeing read after a predetermined time window (e.g., the message contenthas become stale).

The access-control devices can communicate the cover message digest as adistributed hash, in a distributed fashion without requiring a centralserver to serve as a central authority for validated cover messagedigests. For example, the sending device can make the cover messagedigest available for the receiving device via any existing communicationor social-media service, such as in a message on a social-media postingor in an email message. When a receiving device obtains the covermessage digest, the receiving device can verify the authenticity of thecover message digest by sending a validation request to any trustedaccess-control device of the distributed framework. If the cover messagedigest is valid, the access-control device may return an acknowledgement(ACK) message, which acknowledges that the cover message digest isvalid. Otherwise, the access-control device may return a negativeacknowledgement (NACK) message which indicates that the cover messagedigest is not valid, or may perform another predetermined remedialaction.

In some embodiments, if the user behind the receiving device has anaccess-control device that is a member of the distributed framework,this access-control device can include a copy of the block chain ordistributed hash table of all valid cover message digests. Hence, thereceiving device can send the validation request to the localaccess-control device to determine whether the cover message digest isvalid.

If the receiving device receives an ACK message, the receiving devicecan proceed to obtain the corrupted encrypted message from a remoteserver or device (e.g., a secure message server, or any access-controldevice of the distributed framework), to obtain the extracted segmentsof the encrypted message, to recreate the original encrypted message,and to decrypt the encrypted message. However, if the receiving devicereceives a NACK message, the receiving device can alert the user thatthe message does not appear to be authentic or trustworthy. The user canask the sender to submit a new valid cover message digest, or may chooseto proceed to download and decrypt the encrypted message at the user'sown risk.

FIG. 15 illustrates an exemplary computer system that facilitatesautomatic generation of context-aware cover messages for securecommunication in accordance with an embodiment. In this example, asystem 1500 for automated cover message generation can include a memorydevice 1504, a processor 1502, a storage device 1506, a display module1507, an input module 1508, and a communication module 1510.

Storage device 1506 can store instructions which when loaded into memory1504 and executed by processor 1502 cause processor 1502 to perform theaforementioned operations (for a sending device, a receiving device, orboth). More specifically, the instructions stored in storage device 1506can include an encryption/decryption module 1512, a topic managementmodule 1514, and a cover message management module 1516.Encryption/decryption module 1512 is responsible for encrypting anddecrypting a secure message. Topic management module 1514 is responsiblefor uploading locally filtered topic list to the topic server, andreceiving a shared topic list with respect to a particular receivingdevice from the topic server. Cover message management module 1516 isresponsible for generating a context-aware cover message and computing adigest for a generated or received cover message.

Exemplary Embodiments

One embodiment of the present invention provides a personal computingdevice that can push data objects to one or more intended recipients.During operation, the computing device can obtain a data object beingpublished by a user. The computing device can generate a partial messagethat includes a subset of the data object, and can send the partialmessage to an intended recipient of the data object, without firstreceiving a request for the data object from the intended recipient.

In some embodiments, the intended recipient can include a remotepersonal computing device, a remote personal storage device, and/or astorage server.

In some embodiments, the computing device can generate an access keythat includes at least one section of the data object that are not inthe partial message, and may send the access key to an access-controldevice that controls access to the data object, or to a storage server.

In some embodiments, while generating the partial message, the computingdevice can identify, from the data object, one or more data blocks thatare to be made corrupt. The computing device may then extract segment ofa respective data block to make the respective data block corrupt, andmay combine the corrupt data blocks to form the partial message.

In some embodiments, the computing device can generate a cover messagefor the data object, and can send the cover message to the intendedrecipient to facilitate the intended recipient to obtain the data objectbased on the cover message.

In some variations on these embodiments, the computing device cangenerate a digest from the cover message, and can send the digest to anaccess-control device that controls access to the data object.

In some embodiments, the cover message can include an email message, ashort message service (SMS) message, an instant messaging (IM) message,a message posted on a social media service, and/or an audio recording.

In some embodiments, the computing device can encrypt the data objectusing a predetermined encryption key to produce an encrypted message.Moreover, while generating the partial message, the computing device canobtain the at least one sections from the encrypted message, and cangenerate the partial message to include the at least one sections of theencrypted message.

Another embodiment of the present invention includes a non-transitorycomputer-readable storage medium storing instructions that when executedby a computer cause the computer to perform a method, the methodcomprising: obtaining a data object being published by a user;generating a partial message that includes a subset of the data object;and sending the partial message to an intended recipient of the dataobject, without first receiving a request for the data object from theintended recipient.

In some embodiments, the intended recipient includes one or more of: aremote personal computing device; a remote personal storage device; anda storage server.

In some embodiments, the method performed by the computer also includesgenerating an access key that includes at least one section of the dataobject that are not in the partial message; and sending the access keyto an access-control device that controls access to the data object, orto a storage server.

In some embodiments, the method performed by the computer according tothe stored instructions may further include generating the partialmessage involves: identifying, from the data object, one or more datablocks that are to be made corrupt; extracting a segment of a respectivedata block to make the respective data block corrupt; and combining thecorrupt data blocks to form the partial message.

In some embodiments, the method performed by the computer according tothe stored instructions may further include generating a cover messagefor the data object; and sending the cover message to the intendedrecipient, which facilitates the intended recipient to obtain the dataobject based on the cover message.

In some embodiments, the method performed by the computer according tothe stored instructions may further include generating a digest from thecover message; and sending the digest to an access-control device thatcontrols access to the data object.

In some embodiments, the cover message includes one or more of: an emailmessage; a short message service (SMS) message; an instant messaging(IM) message; a message posted on a social media service; and an audiorecording.

In some embodiments, the method performed by the computer according tothe stored instructions may further include encrypting the data objectusing a predetermined encryption key to produce an encrypted message;wherein generating the partial message involves: obtaining the at leastone sections from the encrypted message; and generating the partialmessage to include the at least one sections of the encrypted message.

Another embodiment of the present invention includes an access-controldevice that can control access to encrypted messages. During operation,the access-control device can receive an access key for a data objectbeing shared with at least one intended recipient, and a digestassociated with the data object, and may store the access key and thedigest in a look-up repository. In response to the device receiving arequest for the data object from a remote device, the device may obtaina second digest from the request. Moreover, the device may analyze thesecond digest to determine whether the second digest is valid. Inresponse to validating the second digest, the device may return theaccess key to the remote device.

In some embodiments, while storing the digest, the device may store thedigest in a block chain. A respective block of the block chain caninclude at least one digest, and/or a hash value of a previous block ofthe block chain.

In some embodiments, the access-control device may be a member of adistributed hash table. Responsive to storing the digest in the blockchain, the device may synchronize the block chain with at least oneother member device of the distributed hash table.

In some embodiments, while returning the access key to the remotedevice, the device can perform a lookup operation, using the digest asinput, to obtain an access key that includes the remainder of the dataobject. The access-control device can return the access key to theremote device.

In some embodiments, while validating the second digest, the device mayperform a lookup operation in the block chain to determine whether thesecond digest exists in the block chain.

In some embodiments, the device can return a negative-acknowledgement(NACK) message in response to determining that the second digest doesnot exist in the block chain.

In some embodiments, the device can return an acknowledgement (ACK)message in response to determining that the second digest exists in theblock chain.

In some embodiments, responsive to determining that the second digestexists in a block of the block chain, the device may validate the block.Responsive to determining that the block is valid, the device may returnan acknowledgement (ACK) message.

In some embodiments, responsive to determining that the block is notvalid, the device may return a negative-acknowledgement (NACK) message.

In some embodiments, while validating the block, the device candetermine whether a neighboring block in the block chain includes a hashvalue that matches the block's hash value, and/or can determine whetherthe block and a corresponding block of a remote access-control devicehave matching hash values.

Another embodiment of the present invention may include anaccess-control device, comprising: a communication module operable toreceive an access key for a data object being shared with at least oneintended recipient, and a digest associated with the data object; astorage device operable to store the access key and the digest in alook-up repository;

a digest-lookup module operable to obtain a second digest from a requestreceived from a remote device for the data object; a digest-validationmodule operable to validate the second digest; and an authorizationmodule operable to return the access key to the remote device inresponse to the second digest being valid.

In some embodiments, the storage device is further operable to store thedigest in a block chain, wherein a respective block of the block chainincludes at least one digest, and a hash value of a previous block ofthe block chain.

In some embodiments, the access-control device is a member of adistributed hash table, and the storage device is further operable to,in response to storing the digest in the block chain, synchronize theblock chain with at least one other member device of the distributedhash table.

In some embodiments, the authorization module is further operable toperforming a lookup operation, using the digest as input, to obtain anaccess key that includes the remainder of the data object.

In some embodiments, the digest-validation module is further operable toperform a lookup operation in the block chain to determine whether thesecond digest exists in the block chain.

In some embodiments, the digest-validation module is further operableto: return a negative-acknowledgement (NACK) message, responsive todetermining that the second digest does not exist in the block chain.

In some embodiments, the digest-validation module is further operableto: return an acknowledgement (ACK) message, responsive to determiningthat the second digest exists in the block chain.

In some embodiments, the digest-validation module is further operableto, responsive to determining that the second digest exists in a blockof the block chain: validate the block; and return an acknowledgement(ACK) message responsive to determining that the block is valid.

In some embodiments, the digest-validation module is further operableto: return a negative-acknowledgement (NACK) message responsive todetermining that the block is not valid.

In some embodiments, validating the block involves one or more of:determining whether a neighboring block in the block chain includes ahash value that matches the block's hash value; and determining whetherthe block and a corresponding block of a remote access-control devicehave matching hash values.

The data structures and code described in this detailed description aretypically stored on a computer-readable storage medium, which may be anydevice or medium that can store code and/or data for use by a computersystem. The computer-readable storage medium includes, but is notlimited to, volatile memory, non-volatile memory, magnetic and opticalstorage devices such as disk drives, magnetic tape, CDs (compact discs),DVDs (digital versatile discs or digital video discs), or other mediacapable of storing computer-readable media now known or later developed.

The methods and processes described in the detailed description sectioncan be embodied as code and/or data, which can be stored in acomputer-readable storage medium as described above. When a computersystem reads and executes the code and/or data stored on thecomputer-readable storage medium, the computer system performs themethods and processes embodied as data structures and code and storedwithin the computer-readable storage medium.

Furthermore, the methods and processes described above can be includedin hardware modules. For example, the hardware modules can include, butare not limited to, application-specific integrated circuit (ASIC)chips, field-programmable gate arrays (FPGAs), and otherprogrammable-logic devices now known or later developed. When thehardware modules are activated, the hardware modules perform the methodsand processes included within the hardware modules.

The foregoing descriptions of embodiments of the present invention havebeen presented for purposes of illustration and description only. Theyare not intended to be exhaustive or to limit the present invention tothe forms disclosed. Accordingly, many modifications and variations willbe apparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the present invention. The scope ofthe present invention is defined by the appended claims.

What is claimed is:
 1. A method for facilitating anonymous access to anexternal service, comprising: receiving a request for accessing theexternal service from a user; receiving identifying information of atarget user and a piece of content for the target user; allocating ananonymous user identifier associated with the external service to theuser; and sending the piece of content to the target user via theexternal service based on the anonymous user identifier.
 2. The methodof claim 1, wherein the piece of content includes one or more of: amessage; a document; and a media file.
 3. The method of claim 1, whereinsending the piece of content to the target user further comprisessending a message comprising a link via the external service, whereinthe message indicates that an anonymous user intends to send a piece ofcontent to the target user, and wherein clicking the link provides thepiece of content to the target user.
 4. The method of claim 1, furthercomprising: receiving authenticating information associated with theuser for the external service; and in response to successfullyauthenticating the user with the external service, revealing identity ofthe user to the target user.
 5. The method of claim 4, furthercomprising: determining a messaging mechanism for the target usersending a message to the user via the external service; and allowingdirect message exchange between the user and the target user via themessaging mechanism based on the successful authentication.
 6. Themethod of claim 4, wherein the authenticating information includes oneor more of: a user name; an email address; a phone number; and logincredentials.
 7. The method of claim 1, wherein the external service is amessaging service based on one or more of: a short message service (SMS)message; an instant messaging (IM) message; and a social media messageor post.
 8. The method of claim 1, further comprising selecting thepiece of content from a local device of the user or a network folderassociated with the user.
 9. The method of claim 1, further comprisingreceiving a rule indicating one or more of: a timeline during which thepiece of content is available; and whether the piece of content isforwardable from the target user.
 10. The method of claim 1, furthercomprising receiving, from a device of the target user, a notificationindicating one or more actions performed on the piece of content.
 11. Anon-transitory computer-readable storage medium storing instructionsthat when executed by a computer cause the computer to perform a methodfor facilitating anonymous access to an external service, the methodcomprising: receiving a request for accessing the external service froma user; receiving identifying information of a target user and a pieceof content for the target user; allocating an anonymous user identifierassociated with the external service to the user; and sending the pieceof content to the target user via the external service based on theanonymous user identifier.
 12. The storage medium of claim 11, whereinthe piece of content includes one or more of: a message; a document; anda media file.
 13. The storage medium of claim 11, wherein sending thepiece of content to the target user further comprises sending a messagecomprising a link via the external service, wherein the messageindicates that an anonymous user intends to send a piece of content tothe target user, and wherein clicking the link provides the piece ofcontent to the target user.
 14. The storage medium of claim 11, whereinthe method further comprises: receiving authenticating informationassociated with the user for the external service; and in response tosuccessfully authenticating the user with the external service,revealing identity of the user to the target user.
 15. The storagemedium of claim 14, wherein the method further comprises: determining amessaging mechanism for the target user sending a message to the uservia the external service; and allowing direct message exchange betweenthe user and the target user via the messaging mechanism based on thesuccessful authentication.
 16. The storage medium of claim 14, whereinthe authenticating information includes one or more of: a user name; anemail address; a phone number; and login credentials.
 17. The storagemedium of claim 11, wherein the external service is a messaging servicebased on one or more of: a short message service (SMS) message; aninstant messaging (IM) message; and a social media message or post. 18.The storage medium of claim 11, wherein the method further comprisesselecting the piece of content from a local device of the user or anetwork folder associated with the user.
 19. The storage medium of claim11, wherein the method further comprises receiving a rule indicating oneor more of: a timeline during which the piece of content is available;and whether the piece of content is forwardable from the target user.20. The storage medium of claim 11, wherein the method further comprisesreceiving, from a device of the target user, a notification indicatingone or more actions performed on the piece of content.